Reading the initial data

Importing data from Excel files

Nearly every module in the Atlas BIT system allows you to load master data files based on predefined schemes. The loading routines of the modules are outsourced to extra files in order not to burden the master modules with the additional data code that is not needed during normal operation - they are always named like the top master module with the ending .lod instead of .mod. e.g. customer.lod

These extra files are not included in the normal project, so they have to be requested from ClassiX and imported if necessary.

The directory structure should then look like this:

appswh\[project name]\load\*.lod

This file path must be specified in the CX_PATH in the START.bat

Since the loading routines are generalised, it is always necessary to include the dfltrout.lod. It is also added to the load directory.

The following files are therefore always required to import master data:

• Master .lod file of the module whose data are to be read in
• dfltrout.lod for the generalised loading routines
• Excel file with master data to be imported

The name and the path to the Excel read-in file is hardwired in the respective root .lod module in the macro "NameOfExcelFile". Either the Excel file must be renamed accordingly or the file name in the -lod must be adapted.

Note:
If neither the file name of the Excel file, nor the file path to it in the lod should be adapted, the file name with the path of the Excel file can be written into the variable manualFile before the call "LoadObjects". The read-in routine will then use this file instead of the one hardwired in the .lod.

For example, the read-in call could then look like this:
"Y:\ClassiX\Evaluate\Customer data.xls" -> manualFile LoadObjects

Reading in is started with the command "LoadObjects" on the editing window of the respective module.

Example for files - Here we start from customer data:

Required files:

• customer.lod (in the load directory)
• dfltrout.lod (in the load directory)
• customer.xls (in the projects\data directory)

Structure of Excel files and generalised macros

Generalised:

Name of the Excel file
The name and the path to the Excel file to be read is always in the corresponding .lod file in the macro NameOfExcelFile

Data structure of the Excel file

• In the first line you can read in plain text what should be done in the table column. This note is optional and only for the user. It is not interpreted by the system.
• The second line contains the programme call to be executed for each line in the current column. These are InstantView commands and macro calls from the current module or from the current .lod file, which were created only for reading in.
  Note
  So if a certain program function is only required for reading in, it must be created in the .lod file.
• In all further lines the data to be read in are specified.

database layer:
The folder within the Excel file controls which database layer the data is written to.
The data in folder 1 (always on the far left) is therefore written to the first layer, that of folder 2 to the second, and so on.

Database domains / client separation
Within the database layers, there is another way of dividing the data, namely the domains. In the lod file for general loading routines (dfltrout.lod) there is a macro for this purpose, which always sets the domain correctly on the basis of 2 passed parameters: SetDomainByClass. It expects as first parameter (Stack TOP) the class, which is concerned and as second parameter the domain, which is to be switched to for reading and writing.
2 CX_PARTNER SetDomainByClass would therefore set the domain of CX_PARTNER for reading and writing to 2 in the current layer. Depending on the setting in the system data, this is then the domain of the second client. The data read with this setting can only be found in the partner mask of the second client.

Reading routine
After each line read in, the macro "InitEditObject" from the corresponding .lod file is called, which should always open the empty edit mask. In different modules the EditObject macro call provides a different set of passed parameters. Therefore it is necessary per module to include this NULL EditObject statement with all required parameters in the lod. file with all required parameters.

The following example is intended to illustrate the principle of import interfaces:

Define domain	Enter your name	Ust. Id. No.	Industry	Phone	Save
CX_PARTNER SetDomainByClass	PutValue(, name)	PutValue(, vatID)	PutIndustry	PutDeskPhone	SaveObject
1	Johansdotter & Bensemann GmbH	DE71818463	019	+49-69-7050262-0	NoOperation
2	Gebr. Oevermann conveyor technology KG	DE36288778	016	+49-89-049021-0	NoOperation

• Define domain: In the first column, the client is set. In this case, client 1 receives a partner entry and client 2 another.
  If both clients are to receive the same entries, although they otherwise have separate partner strains, the data must be copied and pasted again with the other domain at the end of the file:

Define domain	Enter your name	Ust. Id. No.	Industry	Phone	Save
CX_PARTNER SetDomainByClass	PutValue(, name)	PutValue(, vatID)	PutIndustry	PutDeskPhone	SaveObject
1	Johansdotter & Bensemann GmbH	DE71818463	019	+49-69-7050262-0	NoOperation
2	Johansdotter & Bensemann GmbH	DE71818463	019	+49-69-7050262-0	NoOperation
1	Gebr. Oevermann conveyor technology KG	DE36288778	016	+49-89-049021-0	NoOperation
2	Gebr. Oevermann conveyor technology KG	DE36288778	016	+49-89-049021-0	NoOperation

• Entering names: In the next column the content of the columns input field "name" on the editing window is entered via the InstantView command "PutValue". When reading in, this command has the same effect as the otherwise manual entry of a value on the editing mask itself.
• Ust. Id. Nr: The next one works like the column "Enter name", but here the input field "vatID" on the input mask is filled in
• Branch: In this column a macro defined in the .lod file is called, which determines a branch by means of the transferred number and enters it on the mask itself.
• Phone: In this column, the telephone number is also sent to a macro, which independently creates a new access object for the partner and stores the transferred telephone number in it.
• Save: The data entered in the mask is saved. A new partner is created. Since only those columns are executed in which a value has been entered in the data rows, these data columns contain the value "NoOperation", which means that the system accepts this value as input but does not do anything further than to proceed to the next command, namely SaveObject.
  By setting a control variable "TRUE -> executeEmptyCells" you can control that the system should execute the empty columns anyway.
  

In this way, existing Excel files can be quickly supplemented by the corresponding first two lines with their columns and read in directly.In this way, existing Excel files can be quickly supplemented by the corresponding first two lines with their columns and read in directly.